The present invention relates to the design of an application specific processor (ASP) and in particular to the use of a modelling tool in the design process to aid the development of architectural modelling.
In a design process of an ASP, a model is constructed based on a CPU and a set of peripherals. Three basic types of data are required to be generated before any xe2x80x9creal modellingxe2x80x9d can start. These can be summarised as follows:
A set of low level functions and constants to aid the integration of a functional model of a peripheral in a modelling language such as C.
A set of low level functions and constants to aid the testing of the functional model. This code would execute on a simulation of the CPU and would also be useful for functional verification.
A register or data structure mapping, indicating the size of various fields within the register, the reset state and its function.
Typically this set of data is generated by hand and must be completed before any real modelling can start. The generation by hand is a laborious task and is prone to all the usual human errors.
It is an object of the present invention to make the task less labour intensive, particularly in respect of the low level communication functions between the peripheral and the processor.
According to one aspect of the present invention there is provided a method of operating a computer system to design an application specific processor (ASP) comprising:
defining a set of peripherals for the ASP which are responsive to stimuli and which communicate with a processor;
generating for each peripheral an input file which defines the functional attributes of that peripheral in a high level language with an input data structure;
entering the file into the computer system and operating a modelling tool loaded on the computer system to generate from the input file at least an interface functions file which defines the communication attributes of the peripheral with the processor and the functional attributes of the peripheral in a manner independent of any particular data structure, and a test functions file which defines the communication attributes of the processor with the peripheral in a manner independent of any particular data structure; and
using the interface functions file and test functions file to generate a functional model in a high level language for simulating the architectural behaviour of the ASP.
According to another aspect of the present invention there is provided a computer system which comprises; a processor and a memory, the memory holding a program representing a modelling tool for use in designing an application specific processor (ASP), wherein the computer system comprises an input means for receiving a plurality of input files, each input file defining the functional attributes of a peripheral for the ASP in a high level language within an input data structure;
the processor being operable to execute the program representing the modelling tool to generate from the input file at least an interface functions file which defines the communication attributes of the peripheral with the processor and the functional attributes of the peripheral in a manner independent of any particular data structure, and a test functions file which defines the communication attributes of the processor with the peripheral in a manner independent of any particular data structure; and
the computer system further comprising an output means for outputting said interface functions file and said test functions file in a manner such that they are usable to generate a functional model in a high level language for simulating the architectural behaviour of the ASP.
The input file can be loaded into the computer on a disk or similar physical recording device. Likewise, the interface functions file and test functions file can be recorded onto a physical recording device such as a disk.
The invention also provides a modelling tool for use in defining an ASP which receives as its input an input file which for each of a set of peripherals defines the functional attributes of that peripheral in a high level language with an input data structure and which generates from the input file.
(i) an interface functions file, which defines the communication attributes of the peripheral with the processor and the functional attributes of the peripheral in a manner independent of any particular data structure,
(ii) a test functions file which defines the communication attributes of the processor with the peripheral in a manner independent of any particular data structure, and
(iii) a register definition file by allocating specific elements of the input data structure to predefined sectors of a register definition table.
The modelling tool described herein ensures that the generation of the above sets of data are completely in sync. It also greatly reduces the time to develop the models of various peripherals by allowing the designer to concentrate on the task at handxe2x80x94that of the peripheral itself. The tool also makes it possible for novice designers to get started using the peripheral modelling much quicker by not having to learn about the finer details of a particular simulator, for example by removing the need to learn details of how to send and receive data from the simulator to the peripheral.
The modelling tool is designed for use in an environment in which a simulator simulates a CPU and a memory system to which peripherals can be added.
Peripheral and subsystem support is provided by allowing the user to define a set of functions for each device that will simulate its behaviour. These functions are compiled into a device library by the user, and loaded by the simulator during execution. All the device libraries for, the devices being simulated are listed in a device definition file. When the simulator is executed, these functions are: dynamically linked with the simulator code.
Each device has an address range associated with it in the device definition file. Any load from or store to, an address in that range will cause the simulator to execute the appropriate peripheral read or write function instead of a memory access.
The following functions are provided in each device library:
An initialization function which is run when the simulation starts before any application code is executed. This function must set up a structure with the names of the other functions.
A loop function which executes regularly. The loop function is used to define asynchronous or delayed behaviour by the device, such as sending an interrupt. Each device has a loop cycle step variable which defines the frequency of execution, i.e. how many instructions are executed between two executions of the loop function. By default, the loop function is executed after every instruction.
A function for each type of signal expected from the CPU. For peripherals this would usually be one function for Load (called the peripheral read) and one for Store (called the peripheral write). These functions are called by the simulator where an appropriate instruction is executed for an address related to the device. They define any immediate device response to the signal, such as sending back a value when a shared register location is loaded.
As an example, suppose that the application running on the CPU executes a load from a peripheral address. At this point the simulator calls the peripheral read function in the peripheral model dynamic library. The peripheral read function returns the data stored at the address and the simulator then places this value onto the stack.
A typical peripheral model and its integration within a functional simulator is shown in FIG. 2. The peripheral is written in a high level language such as C and the code for this model operates upon data structures written in a manner which aids the architecture development. In order for the CPU, and hence code executing on the CPU, to access various bits of state or data, such as a control register, it must read or write to various words in memory. The read peripherals being modelled are memory mapped in the CPU memory space. The states or data structures that are maintained within the model which are visible to the CPU, and hence to the code, must be copied to or from the registers or memory. The simulator has special calls to handle accesses to special areas such as memory.
The peripheral model writer declares an area of memory that is to be treated as special, in this case seen as the registers memory or a data structure memory. When the CPU accesses this area of memory the peripheral model must copy or update its internal representation of the externally visible state. This is usually done by the Read and Write functions in the simulator. These functions allow the modelling to proceed in a free and easy manner, without any constraints on how it should be written or how data should be manipulated and only when it is necessary to transfer the data to the outside world is it done so via these functions. The description of the registers and data structure visible to the CPU within the peripheral will be described within the functional specification document for that peripheral.
The modelling tool described herein automates the generation of the low level functions, constants and the basis of the documentation by using the data structures specified by the peripheral model. There is sufficient information within the specification of these data structures to generate these low level functions and the documentation, using some basic conventions developed by the inventor.
These can be summarised as:
All accesses to the data structures used within the peripheral model are done via functions. These are Query, and Set functions for each attribute (element) for each data structure.
All accesses to the registers are done via functions with a common interface.
The names of all the functions are derived from the attributes and structure definition of the data structures.
All constant names used to access bits within registers are derived from the attributes and structure definition of the data structures.